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(i.) Real Party In Interest 

The real party in interest in the above application is Nokia Corporation. 
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(ii.) Related Appeals and Interferences 

The Appellants know of no other related cases, including any related applications, 
appeals or interferences, that will directly affect, be directly affected by, or have a bearing on the 
Board's decision in the pending appeal. 
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(iii.) Status of Claims 

This is an appeal from the decision of the Examiner in an Office Action dated November 
9, 2010, rejecting claims 1, 4-5, 7-9, 1 1, 20, and 26-32. The pending claims have been twice 
rejected. Claims 1, 4-5, 7-9, 1 1, 20, and 26-32 are the subject of this appeal. 
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(iv.) Status of Amendments 

All amendments for claims 1, 4-5, 7-9, 1 1, 20, and 26-32 have been entered. Appellants 
have filed a Notice of Appeal on February 9, 201 1. 
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(v.) Summary of Claimed Subject Matter 

Background 

The invention relates to communication systems, and in particular to communication 
systems wherein a user may register an identity from multiple locations. [Specification, Page 1, 
Paragraph 1]. 

Appellants' Invention 
Claim 1 

One aspect of Appellants' invention is set out in claim 1 as a method that includes 
registering, in a controller entity comprising a call state control function, a plurality of contact 
addresses for a user. "According to one embodiment of the invention, there is provided a method 
in a communication system for processing incoming requests at a controller entity. The method 
includes the steps of registering a plurality of contact addresses for a user in the controller entity, 
and receiving a request at the controller entity for a communication link to the user." 
[Specification, pages 4-5, paragraph 13]. "The serving call session control function 12 forms 
an entity whereto the subscriber 10 shall be registered at. The registration is required in order to 
be able to request for a service from the communication system. A user may register himself via 
any appropriate access system, such as the shown networks 2 and 4. In FIG. 1 the user 1 is 
shown to have a plurality of contacts 7 registered at the controller entity 12. More particularly, 
contact addresses "contact 1 (ql)" to "contact x (qx)" are provided via the GPRS network 2. 
Contact addresses "contact 2 (q2)" to "contact y (qy)" are provided via the WLAN network 4. All 
these contact are registered at the contact register 14 of the controller entity 12." [Specification, 
page 8, paragraphs 27-28]. "[0034] In the operation, a plurality of addresses for a user may be 
registered at a S-CSCF 12 at step 30 of FIG. 2." [FIG. 2, and Specification, page 9, paragraph 
32]. 

FIG. 2 is a flowchart schematic illustrating operations including the operation of 
registering a plurality of addresses of a user at a S-CSCF. 
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A further inventive feature of Appellants' claim 1 is that the method also includes 
receiving, at the controller entity, a request for a communication link to the user. "According to 
one embodiment of the invention, there is provided a method in a communication system for 
processing incoming requests at a controller entity. The method includes the steps of registering 
a plurality of contact addresses for a user in the controller entity, and receiving a request at the 
controller entity for a communication link to the user." [Specification, pages 4-5, paragraph 
13]. "This example of the invention relates to call set-up procedures when user 6 tries to make a 
call to the mobile user 1 who has multiple registrations at the serving call state control function 
12. It may occur that the called user 2 has not indicated to the S-CSCF 12 any preferences for 
forking of incoming requests via its registration, for example by using the q values. The calling 
user 6 has not indicated any preferences either, for example by using the above discussed 
'Request-Disposition" header field." [Specification, page 9, paragraph 30]. "In the operation, 
a plurality of addresses for a user may be registered at a S-CSCF 12 at step 30 of FIG. 2. An 
incoming request may arrive at step 31 to the S-CSCF 12 to be terminated for the mobile user 1." 
[FIG. 2, and Specification, page 9, Paragraph 32]. 
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Another inventive feature of Appellants' claim 1 is that the method further includes 
querying, by the controller entity, a database at a home subscriber server for information 
regarding a manner regarding how to handle the request. "According to one embodiment of the 
invention, there is provided a method in a communication system for processing incoming 
requests at a controller entity. The method includes the steps of registering a plurality of contact 
addresses for a user in the controller entity, and receiving a request at the controller entity for a 
communication link to the user. The method also includes the steps of querying a user 
information storage for information regarding the manner regarding how to handle the request; 
and processing the request in accordance with the information from the user information 
storage." [Specification, pages 4-5, paragraph 13]. "This example of the invention relates to 
call set-up procedures when user 6 tries to make a call to the mobile user 1 who has multiple 
registrations at the serving call state control function 12. It may occur that the called user 2 has 
not indicated to the S-CSCF 12 any preferences for forking of incoming requests via its 
registration, for example by using the q values. The calling user 6 has not indicated any 
preferences either, for example by using the above discussed " Request-Disposition' header field. 
To avoid an undefined situation, the user profile 22 stored in the subscriber information storage 
20 contains information regarding how the incoming requests shall be handled. The 
implementation of the use of this information may be similar to the fork-directive and the 
parallel-directive as described above. The operator of the HSS 20 is preferably able to provision 
the information stored in the HSS. The operator is also preferably able to modify the statically 
stored information." [Specification, page 9, paragraphs 30-31]. "In the operation, a plurality 
of addresses for a user may be registered at a S-CSCF 12 at step 30 of FIG. 2. An incoming 
request may arrive at step 3 1 to the S-CSCF 12 to be terminated for the mobile user 1 . The user 1 
has not indicated any q values via registration to the S-CSCF 12. Neither does the incoming 
request have any preferences of the caller, for example by means of the ' Request-Disposition' 
header field. In such situation the S-CSCF 12 may query a user information database at step 32. 
The request may then be processed at step 33 in accordance with the user profile 22 stored in the 
HSS 20. For example, the user profile 22 may be configured to indicate the following 
alternatives: proxy to only a single contact (no forking), proxy the request to all known addresses 
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at once (parallel forking), or proxy the request sequentially. In the last case the order may be 
randomly chosen (sequential search). In certain applications two options might be enough. For 
example, the options may be no forking and sequential forking. More than three options may 
also be used." [FIG. 2, and Specification, pages 9-10, paragraphs 32-33]. 

A further inventive feature of Appellants' claim 1 is that the method also includes 
processing, at the controller entity, the request based on the queried information from the 
database. "According to one embodiment of the invention, there is provided a method in a 
communication system for processing incoming requests at a controller entity. The method 
includes the steps of registering a plurality of contact addresses for a user in the controller entity, 
and receiving a request at the controller entity for a communication link to the user. The method 
also includes the steps of querying a user information storage for information regarding the 
manner regarding how to handle the request; and processing the request in accordance with the 
information from the user information storage." [Specification, pages 4-5, paragraph 13]. "To 
avoid an undefined situation, the user profile 22 stored in the subscriber information storage 20 
contains information regarding how the incoming requests shall be handled. The implementation 
of the use of this information may be similar to the fork-directive and the parallel-directive as 
described above. The operator of the HSS 20 is preferably able to provision the information 
stored in the HSS. The operator is also preferably able to modify the statically stored 
information." [Specification, page 9, paragraph 31]. "[0034] In the operation, a plurality of 
addresses for a user may be registered at a S-CSCF 12 at step 30 of FIG. 2. An incoming request 
may arrive at step 3 1 to the S-CSCF 12 to be terminated for the mobile user 1 . The user 1 has not 
indicated any q values via registration to the S-CSCF 12. Neither does the incoming request have 
any preferences of the caller, for example by means of the 'Request-Disposition" header field. In 
such situation the S-CSCF 12 may query a user information database at step 32. The request may 
then be processed at step 33 in accordance with the user profile 22 stored in the HSS 20. For 
example, the user profile 22 may be configured to indicate the following alternatives: proxy to 
only a single contact (no forking), proxy the request to all known addresses at once (parallel 
forking), or proxy the request sequentially. In the last case the order may be randomly chosen 
(sequential search). In certain applications two options might be enough. For example, the 
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options may be no forking and sequential forking. More than three options may also be used. 
The processing may occur in accordance with the information from the user information storage 
only if no user preference has been indicated for the known contact addresses. For example, any 
preference indicated by the request may overrun the information from the user information 
storage. Alternatively, the user information may not even be queried if the request includes a 
preference, or if the preference is otherwise known." [FIG. 2, and Specification, pages 9-10, 
paragraphs 32-34]. 

And Appellants' claim 1 includes the features of wherein, when provided during 
registration, the controller entity uses user preference information to determine whether to fork 
the request in parallel or sequentially. "This example of the invention relates to call set-up 
procedures when user 6 tries to make a call to the mobile user 1 who has multiple registrations at 
the serving call state control function 12. It may occur that the called user 2 has not indicated to 
the S-CSCF 12 any preferences for forking of incoming requests via its registration, for example 
by using the q values. The calling user 6 has not indicated any preferences either, for example by 
using the above discussed "Request-Disposition" header field. To avoid an undefined situation, 
the user profile 22 stored in the subscriber information storage 20 contains information regarding 
how the incoming requests shall be handled. The implementation of the use of this information 
may be similar to the fork-directive and the parallel-directive as described above. The operator of 
the HSS 20 is preferably able to provision the information stored in the HSS. The operator is also 
preferably able to modify the statically stored information. [Specification, page 9, paragraphs 
30-31]. "The processing may occur in accordance with the information from the user 
information storage only if no user preference has been indicated for the known contact 
addresses. For example, any preference indicated by the request may overrun the information 
from the user information storage. Alternatively, the user information may not even be queried if 
the request includes a preference, or if the preference is otherwise known." [Specification, page 
10, paragraph 34]. 

Claim 1 1 
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An additional aspect of Appellants' invention is set out in claim 1 1 as an apparatus that 
includes at least one processor, and at least one memory. "Reference is made to FIG. 1 which 
shows an example of a network architecture wherein the invention may be embodied. FIG. 1 
shows an IP Multimedia Network 10. IP multimedia services may be offered for IP Multimedia 
Network subscribers. IP Multimedia (IM) functionalities can be provided by means of a Core 
Network (CN) subsystem including various entities for the provision of the service. The core 
network (CN) entities typically include various switching and other control entities and gateways 
for enabling the communication via a number of radio access networks and also for interfacing a 
single communication system with one or more communication system such as with other 
cellular systems and/or fixed line communication systems. In the shown arrangement a user 
equipment 1 may access the IMS network 10 via two different access networks 2 and 4. The 
exemplifying network includes a General Packet Radio Service (GPRS) network 2 and a 
Wireless local area network (WLAN) 4. Each access network is provided with base stations 3 
and 5, respectively. The access networks are typically controlled by at least one appropriate 
controllers (not shown for clarity). A controller may be assigned for each base station or a 
controller can control a plurality of base stations. Solutions wherein controllers are provided both 
in individual base stations and in the radio access network level for controlling a plurality of base 
stations are also known. It shall thus be appreciated that the name, location and number of the 
network controllers depends on the system. The base stations 2 and 5 are arranged to transmit 
signals to and receive signals from the mobile user equipment 1 of a mobile user i.e. subscriber 
via a wireless interface. Correspondingly, the mobile user equipment 1 is able to transmit signals 
to and receive signals from the base station via the wireless interface. The mobile user may use 
any appropriate mobile device adapted for Internet Protocol (IP) communication to connect the 
network. For example, the mobile user may access the cellular network by means of a Personal 
computer (PC), Personal Data Assistant (PDA), mobile station (MS) and so on. The following 
examples are described in the context of mobile stations. One skilled in the art is familiar with 
the features and operation of a typical mobile station. Thus, a detailed explanation of these 
features is not necessary. It is sufficient to note that the user may use the mobile station 1 for 
tasks such as for making and receiving phone calls, for receiving and sending data from and to 
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the network and for experiencing e.g., multimedia content. The mobile station may include an 
antenna element for wirelessly receiving and transmitting signals from and to base stations of the 
mobile communication network. The mobile station 1 may also be provided with a display for 
displaying images and other graphical information for the user of the mobile user equipment. 
Speaker means are also typically provided. The operation of the mobile user equipment may be 
controlled by means of an appropriate user interface such as control buttons, voice commands 
and so on. Furthermore, a mobile user equipment is provided with a processor entity and a 
memory means. It shall be appreciated that although only one mobile station is shown in FIG. 1 
for clarity, a number of mobile stations may be in simultaneous communication with each base 
station of the mobile communication system." [Specification, pages 6-7, paragraphs 20-24]. 

Another inventive feature of Appellants' claim 1 1 is that the at least one processor and 
the at least one memory provide operations comprising registering, in a controller entity 
comprising a call state control function, a plurality of contact addresses for a user. "According 
to one embodiment of the invention, there is provided a method in a communication system for 
processing incoming requests at a controller entity. The method includes the steps of registering 
a plurality of contact addresses for a user in the controller entity, and receiving a request at the 
controller entity for a communication link to the user." [Specification, pages 4-5, paragraph 
13]. "The serving call session control function 12 forms an entity whereto the subscriber 10 
shall be registered at. The registration is required in order to be able to request for a service from 
the communication system. A user may register himself via any appropriate access system, such 
as the shown networks 2 and 4. In FIG. 1 the user 1 is shown to have a plurality of contacts 7 
registered at the controller entity 12. More particularly, contact addresses 'contact 1 (ql)' to 
'contact x (qx)' are provided via the GPRS network 2. Contact addresses 'contact 2 (q2)' to 
'contact y (qy)' are provided via the WLAN network 4. All these contact are registered at the 
contact register 14 of the controller entity 12." [Specification, page 8, paragraphs 27-28]. "In 
the operation, a plurality of addresses for a user may be registered at a S-CSCF 12 at step 30 of 
FIG. 2." [FIG. 2, and Specification, page 9, paragraph 32]. 

FIG. 2 is a flowchart schematic illustrating operations including the operation of 
registering a plurality of addresses of a user at a S-CSCF. 
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A further inventive feature of Appellants' claim 1 1 is that the operations provided by the 
at least one processor and the at least one memory also include receiving, at the controller entity, 
a request for a communication link to the user. "According to one embodiment of the invention, 
there is provided a method in a communication system for processing incoming requests at a 
controller entity. The method includes the steps of registering a plurality of contact addresses for 
a user in the controller entity, and receiving a request at the controller entity for a communication 
link to the user." [Specification, pages 4-5, paragraph 13]. "This example of the invention 
relates to call set-up procedures when user 6 tries to make a call to the mobile user 1 who has 
multiple registrations at the serving call state control function 12. It may occur that the called 
user 2 has not indicated to the S-CSCF 12 any preferences for forking of incoming requests via 
its registration, for example by using the q values. The calling user 6 has not indicated any 
preferences either, for example by using the above discussed , Request-Disposition , header 
field." [Specification, page 9, paragraph 30]. "In the operation, a plurality of addresses for a 
user may be registered at a S-CSCF 12 at step 30 of FIG. 2. An incoming request may arrive at 
step 31 to the S-CSCF 12 to be terminated for the mobile user 1." [FIG. 2, and Specification, 
page 9, Paragraph 32]. 
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An additional inventive feature of Appellants' claim 1 1 is that the operations provided by 
the at least one processor and the at least one memory further include querying, by the controller 
entity, a database at a home subscriber server for information regarding a manner regarding how 
to handle the request. 'According to one embodiment of the invention, there is provided a 
method in a communication system for processing incoming requests at a controller entity. The 
method includes the steps of registering a plurality of contact addresses for a user in the 
controller entity, and receiving a request at the controller entity for a communication link to the 
user. The method also includes the steps of querying a user information storage for information 
regarding the manner regarding how to handle the request; and processing the request in 
accordance with the information from the user information storage." [Specification, pages 4-5, 
paragraph 13]. "This example of the invention relates to call set-up procedures when user 6 
tries to make a call to the mobile user 1 who has multiple registrations at the serving call state 
control function 12. It may occur that the called user 2 has not indicated to the S-CSCF 12 any 
preferences for forking of incoming requests via its registration, for example by using the q 
values. The calling user 6 has not indicated any preferences either, for example by using the 
above discussed ' Request-Disposition' header field. To avoid an undefined situation, the user 
profile 22 stored in the subscriber information storage 20 contains information regarding how the 
incoming requests shall be handled. The implementation of the use of this information may be 
similar to the fork-directive and the parallel-directive as described above. The operator of the 
HSS 20 is preferably able to provision the information stored in the HSS. The operator is also 
preferably able to modify the statically stored information." [Specification, page 9, paragraphs 
30-31]. "In the operation, a plurality of addresses for a user may be registered at a S-CSCF 12 at 
step 30 of FIG. 2. An incoming request may arrive at step 31 to the S-CSCF 12 to be terminated 
for the mobile user 1 . The user 1 has not indicated any q values via registration to the S-CSCF 
12. Neither does the incoming request have any preferences of the caller, for example by means 
of the ' Request-Disposition" header field. In such situation the S-CSCF 12 may query a user 
information database at step 32. The request may then be processed at step 33 in accordance with 
the user profile 22 stored in the HSS 20. For example, the user profile 22 may be configured to 
indicate the following alternatives: proxy to only a single contact (no forking), proxy the request 
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to all known addresses at once (parallel forking), or proxy the request sequentially. In the last 
case the order may be randomly chosen (sequential search). In certain applications two options 
might be enough. For example, the options may be no forking and sequential forking. More than 
three options may also be used." [FIG. 2, and Specification, pages 9-10, paragraphs 32-33]. 

Another inventive feature of Appellants' claim 1 1 is that the operations provided by the 
at least one processor and the at least one memory also include processing, at the controller 
entity, the request based on the queried information from the database. "According to one 
embodiment of the invention, there is provided a method in a communication system for 
processing incoming requests at a controller entity. The method includes the steps of registering 
a plurality of contact addresses for a user in the controller entity, and receiving a request at the 
controller entity for a communication link to the user. The method also includes the steps of 
querying a user information storage for information regarding the manner regarding how to 
handle the request; and processing the request in accordance with the information from the user 
information storage." [Specification, pages 4-5, paragraph 13]. "To avoid an undefined 
situation, the user profile 22 stored in the subscriber information storage 20 contains information 
regarding how the incoming requests shall be handled. The implementation of the use of this 
information may be similar to the fork-directive and the parallel-directive as described above. 
The operator of the HSS 20 is preferably able to provision the information stored in the HSS. 
The operator is also preferably able to modify the statically stored information." [Specification, 
pages 4-5, paragraph 33]. "In the operation, a plurality of addresses for a user may be 
registered at a S-CSCF 12 at step 30 of FIG. 2. An incoming request may arrive at step 31 to the 
S-CSCF 12 to be terminated for the mobile user 1 . The user 1 has not indicated any q values via 
registration to the S-CSCF 12. Neither does the incoming request have any preferences of the 
caller, for example by means of the , Request-Disposition , header field. In such situation the S- 
CSCF 12 may query a user information database at step 32. The request may then be processed 
at step 33 in accordance with the user profile 22 stored in the HSS 20." [FIG. 2, and 
Specification, page 9, paragraph 32]. 

And Appellants' claim 1 1 includes the inventive features of wherein, when provided 
during registration, the controller entity uses user preference information to determine whether to 
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fork the request in parallel or sequentially. "This example of the invention relates to call set-up 
procedures when user 6 tries to make a call to the mobile user 1 who has multiple registrations at 
the serving call state control function 12. It may occur that the called user 2 has not indicated to 
the S-CSCF 12 any preferences for forking of incoming requests via its registration, for example 
by using the q values. The calling user 6 has not indicated any preferences either, for example by 
using the above discussed 'Request-Disposition' header field. To avoid an undefined situation, 
the user profile 22 stored in the subscriber information storage 20 contains information regarding 
how the incoming requests shall be handled. The implementation of the use of this information 
may be similar to the fork-directive and the parallel-directive as described above. The operator of 
the HSS 20 is preferably able to provision the information stored in the HSS. The operator is also 
preferably able to modify the statically stored information. [Specification, page 9, paragraphs 
30-31]. "[0036] The processing may occur in accordance with the information from the user 
information storage only if no user preference has been indicated for the known contact 
addresses. For example, any preference indicated by the request may overrun the information 
from the user information storage. Alternatively, the user information may not even be queried if 
the request includes a preference, or if the preference is otherwise known." [Specification, page 
10, paragraph 34]. 

Claim 20 

A further aspect of Appellants' invention is set out in claim 20 as an apparatus that 
includes registration means for registering, in a controller entity comprising a call state control 
function, a plurality of contact addresses for a user. "In the current third generation (3G) 
wireless IP multimedia network architectures it is assumed that several different server entities 
are used for handling different functions. These include entities that handle call session control 
functions (CSCFs). The call session functions may be divided into various categories such as a 
proxy call session control function (P-CSCF), interrogating call session control function (1- 
CSCF), and serving call session control function (S-CSCF). For clarity, FIG. 1 shows only the S- 
CSCF 12. The serving call session control function 12 forms an entity whereto the subscriber 10 
shall be registered at. The registration is required in order to be able to request for a service from 
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the communication system. A user may register himself via any appropriate access system, such 
as the shown networks 2 and 4. In FIG. 1 the user 1 is shown to have a plurality of contacts 7 
registered at the controller entity 12. More particularly, contact addresses "contact 1 (ql)" to 
"contact x (qx)" are provided via the GPRS network 2. Contact addresses "contact 2 (q2)" to 
"contact y (qy)" are provided via the WLAN network 4. All these contact are registered at the 
contact register 14 of the controller entity 12." [Specification, page 8, paragraphs 26-28]. 
'According to one embodiment of the invention, there is provided a method in a communication 
system for processing incoming requests at a controller entity. The method includes the steps of 
registering a plurality of contact addresses for a user in the controller entity, and receiving a 
request at the controller entity for a communication link to the user." [Specification, pages 4-5, 
paragraph 13]. "In the operation, a plurality of addresses for a user may be registered at a S- 
CSCF 12 at step 30 of FIG. 2." [FIG. 2, and Specification, page 9, paragraph 32]. 

FIG. 2 is a flowchart schematic illustrating operations including the operation of 
registering a plurality of addresses of a user at a S-CSCF. 
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A further inventive feature of Appellants' claim 20 is that the apparatus also includes 
interface means, at a controller entity, for interfacing to a database for storing information 
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regarding how to handle a request for the user. "In the current third generation (3G) wireless IP 
multimedia network architectures it is assumed that several different server entities are used for 
handling different functions. These include entities that handle call session control functions 
(CSCFs). The call session functions may be divided into various categories such as a proxy call 
session control function (P-CSCF), interrogating call session control function (1-CSCF), and 
serving call session control function (S-CSCF). For clarity, FIG. 1 shows only the S-CSCF 12. 
The serving call session control function 12 forms an entity whereto the subscriber 10 shall be 
registered at. The registration is required in order to be able to request for a service from the 
communication system. A user may register himself via any appropriate access system, such as 
the shown networks 2 and 4. In FIG. 1 the user 1 is shown to have a plurality of contacts 7 
registered at the controller entity 12. More particularly, contact addresses "contact 1 (ql)" to 
"contact x (qx)" are provided via the GPRS network 2. Contact addresses "contact 2 (q2)" to 
"contact y (qy)" are provided via the WLAN network 4. All these contact are registered at the 
contact register 14 of the controller entity 12. A subscriber information storage is shown to be 
provided by a home subscriber server (HSS) 20. The home subscriber server (HSS) 20 is for 
storing subscriber i.e. user related information. The home subscriber server (HSS) can be queried 
by other function entities over the appropriate interfaces, e.g. during session set-up procedures. 
The subscriber information conventionally includes information such as authentication data (e.g. 
registration identities of the subscriber or the terminals) and so on. The HSS can also be used for 
storing permanently subscriber profile information." [Specification, pages 8-9, paragraphs 26- 
29]. "According to one embodiment of the invention, there is provided a method in a 
communication system for processing incoming requests at a controller entity. The method 
includes the steps of registering a plurality of contact addresses for a user in the controller entity, 
and receiving a request at the controller entity for a communication link to the user." 
[Specification, pages 4-5, paragraph 13]. "This example of the invention relates to call set-up 
procedures when user 6 tries to make a call to the mobile user 1 who has multiple registrations at 
the serving call state control function 12. It may occur that the called user 2 has not indicated to 
the S-CSCF 12 any preferences for forking of incoming requests via its registration, for example 
by using the q values. The calling user 6 has not indicated any preferences either, for example by 
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using the above discussed 'Request-Disposition' header field." [Specification, page 9, 
paragraph 30]. "In the operation, a plurality of addresses for a user may be registered at a S- 
CSCF 12 at step 30 of FIG. 2. An incoming request may arrive at step 31 to the S-CSCF 12 to be 
terminated for the mobile user 1." [FIG. 2, and Specification, page 9, paragraph 32]. 

An additional inventive feature of Appellants' claim 20 is that the apparatus further 
includes querying means for querying, by the controller entity, the database at a home subscriber 
server for information regarding a manner regarding how to handle the request. 'According to 
one embodiment of the invention, there is provided a method in a communication system for 
processing incoming requests at a controller entity. The method includes the steps of registering 
a plurality of contact addresses for a user in the controller entity, and receiving a request at the 
controller entity for a communication link to the user. The method also includes the steps of 
querying a user information storage for information regarding the manner regarding how to 
handle the request; and processing the request in accordance with the information from the user 
information storage." [Specification, pages 4-5, paragraph 13]. "This example of the 
invention relates to call set-up procedures when user 6 tries to make a call to the mobile user 1 
who has multiple registrations at the serving call state control function 12. It may occur that the 
called user 2 has not indicated to the S-CSCF 12 any preferences for forking of incoming 
requests via its registration, for example by using the q values. The calling user 6 has not 
indicated any preferences either, for example by using the above discussed 'Request-Disposition' 
header field. To avoid an undefined situation, the user profile 22 stored in the subscriber 
information storage 20 contains information regarding how the incoming requests shall be 
handled. The implementation of the use of this information may be similar to the fork-directive 
and the parallel-directive as described above. The operator of the HSS 20 is preferably able to 
provision the information stored in the HSS. The operator is also preferably able to modify the 
statically stored information." [Specification, page 9, paragraphs 30-31]. "In the operation, a 
plurality of addresses for a user may be registered at a S-CSCF 12 at step 30 of FIG. 2. An 
incoming request may arrive at step 3 1 to the S-CSCF 12 to be terminated for the mobile user 1 . 
The user 1 has not indicated any q values via registration to the S-CSCF 12. Neither does the 
incoming request have any preferences of the caller, for example by means of the 'Request- 
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Disposition" header field. In such situation the S-CSCF 12 may query a user information 
database at step 32. The request may then be processed at step 33 in accordance with the user 
profile 22 stored in the HSS 20. For example, the user profile 22 may be configured to indicate 
the following alternatives: proxy to only a single contact (no forking), proxy the request to all 
known addresses at once (parallel forking), or proxy the request sequentially. In the last case the 
order may be randomly chosen (sequential search). In certain applications two options might be 
enough. For example, the options may be no forking and sequential forking. More than three 
options may also be used." [FIG. 2, and Specification, pages 9-10, paragraphs 32-33]. 

Another inventive feature of Appellants' claim 20 is that the apparatus also includes 
processing means for processing, at the controller entity, the request based on the queried 
information from the database. "In the current third generation (3G) wireless IP multimedia 
network architectures it is assumed that several different server entities are used for handling 
different functions. These include entities that handle call session control functions (CSCFs). The 
call session functions may be divided into various categories such as a proxy call session control 
function (P-CSCF), interrogating call session control function (1-CSCF), and serving call session 
control function (S-CSCF). For clarity, FIG. 1 shows only the S-CSCF 12. The serving call 
session control function 12 forms an entity whereto the subscriber 10 shall be registered at. The 
registration is required in order to be able to request for a service from the communication 
system. A user may register himself via any appropriate access system, such as the shown 
networks 2 and 4. In FIG. 1 the user 1 is shown to have a plurality of contacts 7 registered at the 
controller entity 12. More particularly, contact addresses "contact 1 (ql)" to "contact x (qx)" are 
provided via the GPRS network 2. Contact addresses "contact 2 (q2)" to "contact y (qy)" are 
provided via the WLAN network 4. All these contact are registered at the contact register 14 of 
the controller entity 12." [Specification, pages 8-9, paragraphs 26-28]. "According to one 
embodiment of the invention, there is provided a method in a communication system for 
processing incoming requests at a controller entity. The method includes the steps of registering 
a plurality of contact addresses for a user in the controller entity, and receiving a request at the 
controller entity for a communication link to the user. The method also includes the steps of 
querying a user information storage for information regarding the manner regarding how to 
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handle the request; and processing the request in accordance with the information from the user 
information storage." [Specification, pages 4-5, paragraph 13]. "To avoid an undefined 
situation, the user profile 22 stored in the subscriber information storage 20 contains information 
regarding how the incoming requests shall be handled. The implementation of the use of this 
information may be similar to the fork-directive and the parallel-directive as described above. 
The operator of the HSS 20 is preferably able to provision the information stored in the HSS. 
The operator is also preferably able to modify the statically stored information." [Specification, 
page 9, paragraph 33]. "In the operation, a plurality of addresses for a user may be registered 
at a S-CSCF 12 at step 30 of FIG. 2. An incoming request may arrive at step 31 to the S-CSCF 
12 to be terminated for the mobile user 1 . The user 1 has not indicated any q values via 
registration to the S-CSCF 12. Neither does the incoming request have any preferences of the 
caller, for example by means of the 'Request-Disposition' header field. In such situation the S- 
CSCF 12 may query a user information database at step 32. The request may then be processed 
at step 33 in accordance with the user profile 22 stored in the HSS 20." [FIG. 2, and 
Specification, page 9, paragraph 32]. 

And Appellants' claim 20 includes the inventive features of wherein, when provided 
during registration, the controller entity uses user preference information to determine whether to 
fork the request in parallel or sequentially. "This example of the invention relates to call set-up 
procedures when user 6 tries to make a call to the mobile user 1 who has multiple registrations at 
the serving call state control function 12. It may occur that the called user 2 has not indicated to 
the S-CSCF 12 any preferences for forking of incoming requests via its registration, for example 
by using the q values. The calling user 6 has not indicated any preferences either, for example by 
using the above discussed 'Request-Disposition' header field. To avoid an undefined situation, 
the user profile 22 stored in the subscriber information storage 20 contains information regarding 
how the incoming requests shall be handled. The implementation of the use of this information 
may be similar to the fork-directive and the parallel-directive as described above. The operator of 
the HSS 20 is preferably able to provision the information stored in the HSS. The operator is also 
preferably able to modify the statically stored information. [Specification, page 9, paragraphs 
30-31]. "The processing may occur in accordance with the information from the user 
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information storage only if no user preference has been indicated for the known contact 
addresses. For example, any preference indicated by the request may overrun the information 
from the user information storage. Alternatively, the user information may not even be queried if 
the request includes a preference, or if the preference is otherwise known." [Specification, page 
10, paragraph 34]. 
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(vi.) Grounds of Rejection to be Reviewed on Appeal 

1) Whether claims 1, 4-5, 7-9, 1 1, 20, 23, 26-32 are obvious over U.S. Patent Publication 
No. 2002/0147845 to Sanchez et al. in view of the non-patent literature "Caller Preferences and 
Callee Capabilities for the Session Initiation Protocol (SIP)," by Rosenberg et al. 
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(vii.) Argument 

Obviousness 

"It is well established that the burden is on the PTO to establish a prima facie showing of 
obviousness, In reFritsch, 972 F.2d. 1260, 23 U.S.P.Q.2d 1780 (C.C.P.A., 1972)." 

The Supreme Court stated in KSR International Co. v. Teleflex Inc., 127 S. Ct. 1727, 
1740-1, 82USPQ2d 1386, 1385 (2007): 

The principles underlying these cases are instructive when the question is 
whether a patent claiming the combination of elements of prior art is 
obvious . When a work is available in one field of endeavor, design 
incentives and other market forces can prompt variations of it, either in the 
same field or a different one. If a person of ordinary skill can implement a 
predictable variation, § 1 03 likely bars its patentability. For the same 
reason, if a technique has been used to improve one device, and a person 
of ordinary skill in the art would recognize that it would improve similar 
devices in the same way, using the technique is obvious unless its actual 
application is beyond his or her skill. Sakraida and Anderson 's-Black Rock 
are illustrative — a court must ask whether the improvement is more 
than the predictable use of prior art elements according to their 
established functions. 

Following these principles may be more difficult in other cases than it is 
here because the claimed subject matter may involve more than the simple 
substitution of one known element for another or the mere application of a 
known technique to a piece of prior art ready for the improvement. Often, 
it will be necessary for a court to look to interrelated teachings of 
multiple patents; the effects of demands known to the design 
community or present in the marketplace; and the background 
knowledge possessed by a person having 1741*1741 ordinary skill in 
the art, all in order to determine whether there was an apparent 
reason to combine the known elements in the fashion claimed by the 
patent at issue. To facilitate review, this analysis should be made explicit. 
See In re Kahn, 441 F.3d 977, 988 (C.A.Fed.2006) ("[R] ejections on 
obviousness grounds cannot be sustained by mere conclusory statements; 
instead, there must be some articulated reasoning with some rational 
underpinning to support the legal conclusion of obviousness"). As our 
precedents make clear, however, the analysis need not seek out precise 
teachings directed to the specific subject matter of the challenged claim, 
for a court can take account of the inferences and creative steps that a 
person of ordinary skill in the art would employ. 
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(Emphasis added) 



Additionally, as stated in MPEP 2143.03: 

2143.03 All Claim Limitations Must Be **>Considered< TR-61 

** "All words in a claim must be considered in judging the patentability of 
that claim against the prior art." In re Wilson, 424 F.2d 1382, 1385, 165 
USPQ 494, 496 (CCPA 1970). If an independent claim is nonobvious 
under 35 U.S. C. 103, then any claim depending therefrom is nonobvious. 
In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988). 

>I. < INDEFINITE LIMITATIONS MUST BE CONSIDERED 

A claim limitation which is considered indefinite cannot be disregarded. If 
a claim is subject to more than one interpretation, at least one of which 
would render the claim unpatentable over the prior art, the examiner 
should reject the claim as indefinite under 35 U.S.C. 1 12, second 
paragraph (see MPEP § 706.03(d)) and should reject the claim over the 
prior art based on the interpretation of the claim that renders the prior art 
applicable. Ex parte Ionescu, 222 USPQ 537 (Bd. Pat. App. & Inter. 1984) 
(Claims on appeal were rejected on indefiniteness grounds only; the 
rejection was reversed and the case remanded to the examiner for 
consideration of pertinent prior art.). Compare In re Wilson, 424 F.2d 
1382, 165 USPQ 494 (CCPA 1970) (if no reasonably definite meaning can 
be ascribed to certain claim language, the claim is indefinite, not obvious) 
and In re Steele, 305 F.2d 859,134 USPQ 292 (CCPA 1962) (it is 
improper to rely on speculative assumptions regarding the meaning of a 
claim and then base a rejection under 35 U.S.C. 103 on these 
assumptions). 

>II. < LIMITATIONS WHICH DO NOT FIND SUPPORT IN THE 
ORIGINAL SPECIFICATION MUST BE CONSIDERED 

When evaluating claims for obviousness under 35 U.S.C. 103, all the 
limitations of the claims must be considered and given weight, including 
limitations which do not find support in the specification as originally 
filed (i.e., new matter). Ex parte Grasselli, 231 USPQ 393 (Bd. App. 
1983) affdmem. 738 F.2d 453 (Fed. Cir. 1984) (Claim to a catalyst 
expressly excluded the presence of sulfur, halogen, uranium, and a 
combination of vanadium and phosphorous. Although the negative 
limitations excluding these elements did not appear in the specification as 
filed, it was error to disregard these limitations when determining whether 
the claimed invention would have been obvious in view of the prior art.). 

(Emphasis in the original) 
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Thus, to establish a case of obviousness, the Examiner needs to identify in the prior art all 
the elements of the claim being rejected, and articulate a reason to combine the known elements 
of the prior art in the manner claimed. 

In KSR, the Supreme Court rejected the "rigid" teaching suggestion motivation (TSM) 
requirement applied by the Federal Circuit, since the Court's obviousness decisions had all 
advocated a flexible and functional approach that cautioned against "granting a patent based on 
the combination of elements found in the prior art." With respect to the genesis of the TSM 
requirement, the Court noted that although "[a]s is clear from cases such as Adams 1 , a patent 
composed of several elements is not proved obvious merely by demonstrating that each of its 
elements was, independently, known in the prior art. Although common sense directs one to 
look with care at a patent application that claims as innovation the combination of two known 
devices according to their established functions, it can be important to identify a reason that 
would have prompted a person of ordinary skill in the relevant field to combine the elements in 
the way the claimed new invention does. This is so because inventions in most, if not all, 
instances rely upon building blocks long since uncovered, and claimed discoveries almost of 
necessity will be combinations of what, in some sense, is already known," KSR, 127 S. Ct. 1727 
at 1741. 

In application of the TSM requirement, the Court cautioned that: "Helpful insights, 
however, need not become rigid and mandatory formulas; and when it is so applied, the TSM test 
is incompatible with our precedents," KSR, 127 S. Ct. 1727 at 1741 . 

Courts have also indicated, in relation to obviousness-based rejections, that: 

• The mere fact that the prior art could be so modified would not have made the 
modification obvious unless the prior art suggested the desirability of the 
modification." In re Gordon, 221 U.S.P.Q. 1125, 1127 (Fed. Cir. 1984). 

• "The claimed invention must be considered as a whole, and the question is 
whether there is something in the prior art as a whole to suggest the desirability, and 

1 United States v. Adams, 383 U. S. 39, 40 (1966) 
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thus the obviousness, of making the combination." Lindemann Maschinenfabrik 
GMBHv. American Hoist & Derrick, 221 U.S.P.Q. 481, 488 (Fed. Cir. 1984). 
• "The critical inquiry is whether 'there is something in the prior art as a whole to 
suggest the desirability, and thus the obviousness, of making the combination.'" 
Fromson v. Advance Offset Plate, Inc., 225 U.S.P.Q. 26, 31 (Fed. Cir. 1985). 



Furthermore, as explained by MPEP 2143.01(V), a prima facie case of obviousness 

cannot be established if the combination renders the prior art reference(s) being modified 

unsatisfactory for its intended purpose: 

"If proposed modification would render the prior art invention being 
modified unsatisfactory for its intended purpose, then there is no 
suggestion or motivation to make the proposed modification. In re 
Gordon, 733 F.2d 900, 221 USPQ 1 125 (Fed. Cir. 1984) (Claimed device 
was a blood filter assembly for use during medical procedures wherein 
both the inlet and outlet for the blood were located at the bottom end of 
the filter assembly, and wherein a gas vent was present at the top of the 
filter assembly. The prior art reference taught a liquid strainer for 
removing dirt and water from gasoline and other light oils wherein the 
inlet and outlet were at the top of the device, and wherein a pet-cock 
(stopcock) was located at the bottom of the device for periodically 
removing the collected dirt and water. The reference further taught that the 
separation is assisted by gravity. The Board concluded the claims were 
prima facie obvious, reasoning that it would have been obvious to turn the 
reference device upside down. The court reversed, finding that if the prior 
art device was turned upside down it would be inoperable for its intended 
purpose because the gasoline to be filtered would be trapped at the top, the 
water and heavier oils sought to be separated would flow out of the outlet 
instead of the purified gasoline, and the screen would become clogged." 



Additionally, as further explained in MPEP 2 143. 01 (VI), a prima facie case of 
obviousness cannot be established if the combination changes the principle of operation of the 
prior art reference(s) being modified: 

"If the proposed modification or combination of the prior art would 
change the principle of operation of the prior art invention being modified, 
then the teachings of the references are not sufficient to render the claims 
prima facie obvious. In re Ratti, 270 F.2d 810, 123 USPQ 349 (CCPA 
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1959) (Claims were directed to an oil seal comprising a bore engaging 
portion with outwardly biased resilient spring fingers inserted in a resilient 
sealing member. The primary reference relied upon in a rejection based on 
a combination of references disclosed an oil seal wherein the bore 
engaging portion was reinforced by a cylindrical sheet metal casing. 
Patentee taught the device required rigidity for operation, whereas the 
claimed invention required resiliency. The court reversed the rejection 
holding the "suggested combination of references would require a 
substantial reconstruction and redesign of the elements shown in [the 
primary reference] as well as a change in the basic principle under which 
the [primary reference] construction was designed to operate." 270 F.2d at 
813, 123 USPQ at 352.)." 
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(1) Claims 1, 4-5, 11, 20, 26-27, 
and 29-32 are patentable over the 
cited art. 

For the purposes of this appeal only, claims 1, 4-5, 1 1, 20, 26-27, and 29-32 stand or fall 
together. Claim 1 is representative of this group of claims. 

(A) The prior art fails to disclose the features of "wherein, when provided during registration, 
the controller entity uses user preference information to determine whether to fork the 
request in parallel or sequentially." 

Independent claim 1 recites "a method, comprising: registering, in a controller entity 
comprising a call state control function, a plurality of contact addresses for a user; receiving, at 
the controller entity, a request for a communication link to the user; querying, by the controller 
entity, a database at a home subscriber server for information regarding a manner regarding how 
to handle the request; and processing, at the controller entity, the request based on the queried 
information from the database, wherein, when provided during registration, the controller entity 
uses user preference information to determine whether to fork the request in parallel or 
sequentially." 

Thus, in some embodiments, for a user (a called party) that has a plurality of contact 
addresses, determining which contact address the user may be at may be performed by proxying 
a call request (from a calling party) to a single user address at a time (i.e., no forking), or 
proxying the request to multiple contact addresses of the user (i.e., parallel forking). In 
situations where the user (i.e., the called party) provided preference information at the time of 
registration on what proxying procedure is to be performed (parallel forking, or no forking), that 
information is used to handle the call request processing. 

[0028] In FIG. 1 the user 1 is shown to have a plurality of contacts 7 
registered at the controller entity 12. More particularly, contact addresses 
"contact 1 (ql)" to "contact x (qx)" are provided via the GPRS network 2. 
Contact addresses "contact 2 (q2)" to "contact y (qy)" are provided via the 
WLAN network 4. All these contact are registered at the contact register 
14 of the controller entity 12. 
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[0029] A subscriber information storage is shown to be provided by a 
home subscriber server (HSS) 20. The home subscriber server (HSS) 20 is 
for storing subscriber i.e. user related information. The home subscriber 
server (HSS) can be queried by other function entities over the appropriate 
interfaces, e.g. during session set-up procedures. The subscriber 
information conventionally includes information such as authentication 
data (e.g. registration identities of the subscriber or the terminals) and so 
on. The HSS can also be used for storing permanently subscriber profile 
information. 

[0030] This example of the invention relates to call set-up procedures 
when user 6 tries to make a call to the mobile user 1 who has multiple 
registrations at the serving call state control function 12. It may occur that 
the called user 2 has not indicated to the S-CSCF 12 any preferences for 
forking of incoming requests via its registration, for example by using the 
q values. The calling user 6 has not indicated any preferences either, for 
example by using the above discussed 'Request-Disposition' header field. 

[003 1] To avoid an undefined situation, the user profile 22 stored in the 
subscriber information storage 20 contains information regarding how the 
incoming requests shall be handled. The implementation of the use of this 
information may be similar to the fork-directive and the parallel-directive 
as described above. The operator of the HSS 20 is preferably able to 
provision the information stored in the HSS. The operator is also 
preferably able to modify the statically stored information. 

[0032] In the operation, a plurality of addresses for a user may be 
registered at a S-CSCF 12 at step 30 of FIG. 2. An incoming request may 
arrive at step 31 to the S-CSCF 12 to be terminated for the mobile user 1. 
The user 1 has not indicated any q values via registration to the S-CSCF 
12. Neither does the incoming request have any preferences of the caller, 
for example by means of the 'Request-Disposition' header field. In such 
situation the S-CSCF 12 may query a user information database at step 32. 
The request may then be processed at step 33 in accordance with the user 
profile 22 stored in the HSS 20. 

(Specification, pages 8-9, paragraphs 28-32). 



In rejecting independent claim 1, the Examiner admitted "[h]owever, Sanchez does not 
explicitly disclose the terms "the controller entity uses user preference information to determine 
whether to fork the request in parallel or sequentially" (Emphasis in the original, Office Action, 
page 3). Indeed, Sanchez, which is directed to a method and apparatus for networks which 
enable the appropriate server to be found for providing a specific user with a specific service 
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(Sanchez, page 1, paragraph 3), does not discuss sequential request processing (i.e., no forking) 
or parallel request processing (parallel forking). 

The Examiner, however, relied on Rosenberg as allegedly disclosing the feature of using 
user preference information to determine whether to fork the request in parallel or sequentially, 
and stated: 

"ROSENBERG teaches that it is well known to have system wherein 
processing, at the controller entity, wherein when provided during 
registration, the controller entity uses user preference information to 
determine whether to fork the request in parallel or sequentially' is 

met here by ROSENBERG (page. 6-8, Overview of Operation, Para. 4. 
Extracting Implicit Preferences, e.g., when a caller sends a request, it can 
optionally include new header fields which request certain handling at a 
server. These preferences fall into two categories. The first category, 
called request handling preferences, are carried in the Request-Disposition 
header field. They describe specific behavior that is desired at a server. 
Request handling preferences include whether the caller wishes the server 
to proxy or redirect, and whether sequential or parallel search is desired. 
These preferences can be applied at every proxy or redirect server on the 
call signaling path) in order to make the system efficient. 

(Emphasis in the original, Office Action, page 4). 



The Examiner's characterization of the art relied upon, and the Examiner's arguments in 
relation to the rejection of claim 1, are incorrect. 

Rosenberg is directed to a set of extensions to the Session Initiation Protocol (SIP) which 
allow a caller to express preferences about request handling in servers (Rosenberg, Abstract). 
Rosenberg describes that the extension defines a set of additional parameters to the Contact 
header field, called feature parameters, and that when a User Agent (UA) registers, it places 
these parameters in the Contact header field value to provide a feature set for a URI it is 
registering. Rosenberg further describes that a proxy can use this feature set to route requests 
based on caller preferences, and explains that when a caller sends a request, it can optionally 
include new header fields which request certain handling at a server, and define the caller's 
handling preferences. 
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4 Overview of Operation 

This extension defines a set of additional parameters to the Contact 
header field, called feature parameters. Each parameter name is an 
encoded feature tag, as defined in RFC 2703 [23], that defines a capability 
for the UA associated with the Contact header field value. For example, 
there is a parameter for the SIP methods supported by the UA. Each 
feature parameter has a value; that value is the set of feature values for that 
feature tag. Put together, all of the feature parameters specify a feature set 
that is supported by the UA associated with that Contact header field 
value. 

When a UA registers, it places these parameters in the Contact header 
field value to provide a feature set for a URI it is registering. The feature 
parameters are also mirrored in the Contact header field in a REGISTER 
response. The proxy can use this feature set to route requests based on 
caller preferences. Furthermore, Contact header fields in requests and 
responses that establish a dialog can contain these parameters. That allows 
a UA in a dialog to indicate its feature set to its peer. For example, by 
including the "msgserver" feature tag with value "TRUE" in the 200 OK 
to an INVITE, the LAS can indicate to the UAC that it is a voicemail 
server. This information is useful for user interfaces, as well as automated 
call handling. 

When a caller sends a request, it can optionally include new header 
fields which request certain handling at a server. These preferences fall 
into two categories. The first category, called request handling 
preferences, are carried in the Request-Disposition header field. They 
describe specific behavior that is desired at a server. Request handling 
preferences include whether the caller wishes the server to proxy or 
redirect, and whether sequential or parallel search is desired. These 
preferences can be applied at every proxy or redirect server on the call 
signaling path. 

The second category of preferences, called feature preferences, are carried 
in the Accept-Contact and Reject-Contact header fields. These header 
fields also contain feature sets, represented by the same feature parameters 
that are used in the Contact header field. Here, the feature parameters 
represent the caller's preferences. The Accept-Contact header field 
contains feature sets that describe UAs that the caller would like to reach. 
The Reject-Contact header field contains feature sets which, if matched by 
a UA, imply that the request should not be routed to that UA. 

Proxies use the information in the Accept-Contact and Reject-Contact 
header fields to select amongst contacts in their target set. When neither of 
those header fields are present, the proxy computes implicit preferences 
from the request. These are caller preferences that are not explicitly placed 
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into the request, but can be inferred from the presence of other message 
components. As an example, if the request method is INVITE, this is an 
implicit preference to route the call to a UA that supports the INVITE 
method. 

(Emphasis added, Rosenberg, pages 8-9) 



If the proxy did not find any explicit preferences in the request (from the caller), the 
proxy extracts implicit preferences implied by the presence of other information in the request 
(Rosenberg, page 19). 

Rosenberg additionally describes that the Request-Disposition header field, specifying 
the caller's preferences , includes a list of tokens that each specifies a particular directive, with 
one of those directives being a fork-directive: 

The Request-Disposition header field specifies caller preferences for how 
a server should process a request. Its value is a list of tokens, each of 
which specifies a particular directive. Its syntax is specified in Section 10. 
Note that a compact form, using the letter d, has been defined. The 
directives are grouped into types. There can only be one directive of each 
type per request (i.e., you can't have both "proxy" and "redirect" in the 
same Request-Disposition header field). When the caller specifies a 
directive, the server SHOULD honor that directive. 

The following types of directives are defined: 



fork-directive: This type of directive indicates whether a proxy 
should fork a request ("fork"), or proxy to only a single address 
("no-fork"). If the server is requested not to fork, the server 
SHOULD proxy the request to the "best" address (generally the 
one with the highest q-value). The directive is ignored if "redirect" 
has been requested. 

(Rosenberg, pages 29-30) 



Thus, while Rosenberg describes that a proxy can use a feature set to route requests based 
on caller preferences, and that the caller's preferences may include a fork directive indicating 
how a proxy should fork a request, Rosenberg does not describe that preferences of a called user 



-33- 



Attorney's Docket No.: 39700-79300 1US/NC39973US 
Customer Number: 64046 

(i.e., the party to whom the caller's call request is to be sent) are used to determine the manner of 
forking the request. Accordingly, contrary to the Examiner's contentions, Rosenberg too fails to 
disclose or suggest at least the features of "wherein, when provided during registration, the 
controller entity uses user preference information to determine whether to fork the request in 
parallel or sequentially," as recited in independent claim 1. 

Appellants also note that claim 1 recites "receiving, at the controller entity, a request for a 
communication link to the user ," and, thus, the "user" referred to in claim is the destination or 
target (i.e., called) party, and accordingly, the language of "user preference information" 
unambiguously refers to preference information of the party being called, not the calling party. 

Because neither Sanchez nor Rosenberg disclose or suggest, alone or in combination, at 
least the features of "wherein, when provided during registration, the controller entity uses user 
preference information to determine whether to fork the request in parallel or sequentially," for 
this reason alone, Appellants' independent claim 1 is therefore allowable over the cited art, and 
the rejection under 35 U.S.C. §103(a) of this claim should be withdrawn. 



(B) The prior art fails to disclose the features of "registering, in a controller entity comprising 
a call state control function, a plurality of contact addresses for a user." 

Independent claim 1 recites "a method, comprising: registering, in a controller entity 
comprising a call state control function, a plurality of contact addresses for a user." 

Thus, as noted above, in some embodiments, a user (a called party) may register, in a 
controller entity that includes a CSCF, a plurality of contact addresses to which a subsequent call 
request (from a calling user) may be routed. For example, the Specification states: 

[0028] In FIG. 1 the user 1 is shown to have a plurality of contacts 7 
registered at the controller entity 12. More particularly, contact addresses 
"contact 1 (ql)" to "contact x (qx)" are provided via the GPRS network 2. 
Contact addresses "contact 2 (q2)" to "contact y (qy)" are provided via the 
WLAN network 4. All these contact are registered at the contact register 
14 of the controller entity 12. 
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(Specification, page 8, paragraphs 28). 



In rejecting independent claim 1, the Examiner stated: 

Regarding claim 1, Sanchez teaches wherein a method comprising: 
registering, in a controller entity comprising a call state control 
function is met here by Sanchez ([0047; 0062-0063. 00661 e.g., the CSCF 
(Service Requester Node) receives a REGISTER request (S-10)), a 
plurality of contact addresses for a user is met here by Sanchez ([001 1] 
e.g., plurality of user identifiers under different service environments). 

(Emphasis in the original, Office Action, pages 2-3). 



The Examiner's characterization of the art relied upon, and the Examiner's arguments in 
relation to the rejection of claim 1, are incorrect. 

As noted, Sanchez is directed to a method and apparatus for networks which enable the 
appropriate server to be found for providing a specific user with a specific service, without 
restricting the types of identifications which may be used for both the user and the server 
providing the service (Sanchez, page 1, paragraph 3). Sanchez explains that a User Distribution 
Server (UDS) includes a plurality of user identifiers for identifying a user under different service 
environments, and further explains that the UDS responds to a query pertaining to a specific user 
by redirecting the query to the appropriate server or serving entity, in a network having multiple 
servers. Specifically: 

[001 1] Embodiments of the present invention solve the problem discussed 
above by placing a user identification distributor accessible to an entity 
disposed to request user information. The distributor, or User Distribution 
Server (UDS) comprises a plurality of user identifiers per subscriber basis 
that are intended for identifying a user under different service 
environments. The UDS responds to a query pertaining to a specific user 
by redirecting the query to the appropriate server or serving entity, in a 
network having multiple servers. It is to be understood that "redirecting" 
in this context means answering the query with a server identifier, for the 
requester node issuing a new query towards the server. The UDS 
implements a secondary database with user and server identification 
information obtained from primary user databases, and is arranged for 
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determining a specific network server in charge of a given user under a 
particular service environment. These specific network servers are 
considered primary databases wherein subscribers, or more specifically, 
user data under particular service environment, are distributed. Thus, the 
UDS acts as a secondary database comprising means for recovering user 
identifiers and necessary service data from the specific network servers 
acting as primary databases as well as from other UDS in the network 
resolution domain. The UDS also comprise storage for user identifiers and 
necessary service data, if any, per specific network server. 

(Sanchez, pages 1-2, paragraph 1 1). 



Sanchez also describes that the UDS acts as a secondary database into which user 
identifiers (and other necessary service data) are downloaded from servers acting as primary 



[0024] In accordance with an aspect of the present invention, a User 
Distribution Server (hereinafter UDS) is provided in a network resolution 
domain for receiving service request related queries for specific users in 
particular service environments. The UDS is arranged for acting as a 
secondary database that comprises a plurality of user identifiers on a per 
subscriber basis, each user identifier applicable in a particular service 
environment and associated with a server identifier addressing the 
particular server currently in charge of corresponding user data. These 
particular servers are arranged for acting as primary databases from which 
user identifiers and necessary service data arc downloaded into the UDS 
acting as secondary database. The UDS answers a service request related 
query for a specific user to any service requester node by providing the 
server identifier to further address the particular server currently serving 
the user in the applicable service environment. 

(Sanchez, page 2, paragraph 24). 

Thus, while Sanchez' UDS enables storing multiple identifiers, Sanchez does not 
describe that such multiple user identifiers are registered at the UDS. 

Accordingly, for this reason alone, Sanchez fails to disclose or suggest at least the 
features of "registering, in a controller entity comprising a call state control function, a plurality 
of contact addresses for a user," as recited in Appellants' independent claim 1. 



-36- 



Attorney's Docket No.: 39700-79300 1US/NC39973US 
Customer Number: 64046 

With respect to the Examiner's reference to paragraphs 47, 62-63 and 66 of Sanchez as 
allegedly disclosing the feature of claim 1 pertaining to "registering." Sanchez' paragraph 62, for 
example, provides as follows: 

[0062] An aspect of particular interest is the optimal behaviour of an UDS 
according to the invention acting as an SLF and thus inter- working with 
the CSCF during the Registration phase. The explanations following this 
are aimed with reference to interfaces and entities in FIG. 1 . First, the 
CSCF (Service Requester Node) receives a REGISTER request (S-10) and 
must initiate a query for the location of the subscriber's data. Second, the 
CSCF sends an operation S LF QUERY like (S-20) to the SLF (UDS-1) 
and includes the subscriber identity as stated in the REGISTER request. 
The protocol to use is not significant at this point since the UDS according 
to the invention may be equipped with a plurality of Protocol Handler 
Modules (PHM), as shown in FIG. 3A, in a manner such as being 
appropriate for communicating with DNS, DIAMETER, RADIUS or any 
other suitable protocol. Moreover, the aforementioned Protocol 
Adaptation Entity 32 in FIG. 3B may be interposed between the CSCF and 
the UDS to this end. Third, and still with reference to FIG. 1, the SLF 
(UDS-1) looks up its own database contents as shown in FIG. 2 by way of 
example for the queried subscriber identity. Fourth, and again with 
reference to FIG. 1, the SLF (UDS-1) answers (S-30) with the HSS name 
in which the subscriber's data can be found. Fifth, the CSCF preferably 
launches a query directly to the HSS (Server-3) (S-40). Alternatively to 
the fifth step above and under certain call premises, the CSCF (Service 
Requester Node 28) may proceed by returning the query result (S-45) to 
the External Client 26 having issued the Registration request, for said 
External Client querying (S-50) the appropriate HSS (Server-3). 

(Sanchez, pages 5-6, paragraph 62). 



As shown in Sanchez' FIG. 1, the REGISTER request (S-10) is sent from an external 
client 26 to a Service Requester Node 28 to, presumably, register the external client. Sanchez, 
however, does not describe registering a plurality of contact addresses for a particular user. 

Accordingly, for this reason too, Sanchez fails to disclose or suggest at least the features 
of "registering, in a controller entity comprising a call state control function, a plurality of 
contact addresses for a user," as recited in Appellants' independent claim 1. 
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Rosenberg fails to cure the deficiencies of Sanchez as they pertain to the features of 
"registering, in a controller entity comprising a call state control function, a plurality of contact 
addresses for a user." 

Because neither Sanchez nor Rosenberg disclose or suggest, alone or in combination, at 
least the features of "registering, in a controller entity comprising a call state control function, a 
plurality of contact addresses for a user," for this additional reason, Appellants' independent 
claim 1 is therefore allowable over the cited art, and the rejection under 35 U.S.C. § 103(a) of this 
claim should be withdrawn. 



(C) The prior art fails to disclose the features of "querying, by the controller entity, a 

database at a home subscriber server for information regarding a manner regarding how 
to handle the request." 



Independent claim 1 recites "a method, comprising: registering, in a controller entity 
comprising a call state control function, a plurality of contact addresses for a user; receiving, at 
the controller entity, a request for a communication link to the user, querying, by the controller 
entity, a database at a home subscriber server for information regarding a manner regarding how 
to handle the request" (emphasis added). 

Thus, in some embodiments, the controller entity queries a database at a HSS for 
information regarding the manner in which the request for the communication link to the user 
is to be handled. As explained in the Specification: 

[0032] In the operation, a plurality of addresses for a user may be 
registered at a S-CSCF 12 at step 30 of FIG. 2. An incoming request may 
arrive at step 3 1 to the S-CSCF 12 to be terminated for the mobile user 1 . 
The user 1 has not indicated any q values via registration to the S-CSCF 
12. Neither does the incoming request have any preferences of the caller, 
for example by means of the "Request-Disposition header field. In such 
situation the S-CSCF 12 may query a user information database at step 32. 
The request may then be processed at step 33 in accordance with the user 
profile 22 stored in the HSS 20. 

(Specification, page 9, paragraph 32). 
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In rejecting independent claim 1, the Examiner stated: 

querying, by the controller entity, a database at a home subscriber 
server for information regarding a manner regarding how to handle 
the request is met here by Sanchez ([0062] e.g., the CSCF preferably 
launches a query directly to the HSS (Server-3) (S-40)); 

(Emphasis in the original, Office Action, page 3). 



The Examiner's characterization of the art relied upon, and the Examiner's arguments in 
relation to the rejection of claim 1, are incorrect. 

Sanchez' paragraph 62, which the Examiner alleges discloses the feature of "querying, by 
the controller entity, a database at a home subscriber server for information regarding a manner 
regarding how to handle the request, provides: 

[0062] An aspect of particular interest is the optimal behaviour of an UDS 
according to the invention acting as an SLF and thus inter-working with 
the CSCF during the Registration phase. The explanations following this 
are aimed with reference to interfaces and entities in FIG. 1 . First, the 
CSCF (Service Requester Node) receives a REGISTER request (S-10) and 
must initiate a query for the location of the subscriber's data. Second, the 
CSCF sends an operation S LF QUERY like (S-20) to the SLF (UDS-1) 
and includes the subscriber identity as stated in the REGISTER request. 
The protocol to use is not significant at this point since the UDS according 
to the invention may be equipped with a plurality of Protocol Handler 
Modules (PHM), as shown in FIG. 3A, in a manner such as being 
appropriate for communicating with DNS, DIAMETER, RADIUS or any 
other suitable protocol. Moreover, the aforementioned Protocol 
Adaptation Entity 32 in FIG. 3B may be interposed between the CSCF and 
the UDS to this end. Third, and still with reference to FIG. 1, the SLF 
(UDS-1) looks up its own database contents as shown in FIG. 2 by way of 
example for the queried subscriber identity. Fourth, and again with 
reference to FIG. 1, the SLF (UDS-1) answers (S-30) with the HSS name 
in which the subscriber's data can be found. Fifth, the CSCF preferably 
launches a query directly to the HSS (Server-3) (S-40). Alternatively to 
the fifth step above and under certain call premises, the CSCF (Service 
Requester Node 28) may proceed by returning the query result (S-45) to 
the External Client 26 having issued the Registration request, for said 
External Client querying (S-50) the appropriate HSS (Server-3). 
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(Sanchez, pages 5-6, paragraph 62). 

While this paragraph describes, as noted by the Examiner, that "the CSCF preferably 
launches a query directly to the HSS (Server-3) (S-40)," Sanchez does not describe, in this 
paragraph or elsewhere, that a query sent by Sanchez' CSCF to the HSS is a query to get 
information regarding the manner on how to handle the request for a communication link to a 
user. 

Accordingly, contrary to the Examiner's contentions, Sanchez fails to disclose or suggest 
at least the features of "querying, by the controller entity, a database at a home subscriber server 
for information regarding a manner regarding how to handle the request," as recited in 
Appellants' claim 1. 

Rosenberg fails to cure the deficiencies of Sanchez as they pertain to the features of 
"querying, by the controller entity, a database at a home subscriber server for information 
regarding a manner regarding how to handle the request." 

Because neither Sanchez nor Rosenberg disclose or suggest, alone or in combination, at 
least the features of "querying, by the controller entity, a database at a home subscriber server for 
information regarding a manner regarding how to handle the request," for this additional reason, 
Appellants' independent claim 1 is therefore allowable over the cited art, and the rejection under 
35 U.S.C. § 103(a) of this claim should be withdrawn. 



(D) Sanchez cannot be combined with Rosenberg. 

In rejecting claim 1, the Examiner argued as follows: 

"ROSENBERG teaches that it is well known to have system wherein 
processing, at the controller entity, wherein when provided during 
registration, the controller entity uses user preference information to 
determine whether to fork the request in parallel or sequentially' is 

met here by ROSENBERG (page. 6-8, Overview of Operation, Para. 4. 
Extracting Implicit Preferences, e.g., when a caller sends a request, it can 
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optionally include new header fields which request certain handling at a 
server. These preferences fall into two categories. The first category, 
called request handling preferences, are carried in the Request-Disposition 
header field. They describe specific behavior that is desired at a server. 
Request handling preferences include whether the caller wishes the server 
to proxy or redirect, and whether sequential or parallel search is desired. 
These preferences can be applied at every proxy or redirect server on the 
call signaling path) in order to make the system efficient. Thus it would 
have been obvious to one ordinary skill in the art to modify Sanchez 
invention by utilizing a system in which the called party to be able to 
manipulate callers request and redirect the responses back based on the 
callers request or preferences. 



(Emphasis in the original, Office Action, page 4). 



The Examiner's contentions that it would have been obvious to modify Sanchez (based 
on the teachings of Rosenberg) are incorrect. 

As noted, Rosenberg describes a proxy that can use a feature set to route requests based 
on caller preferences, and further describes that the caller's preferences may include a fork 
directive indicating how a proxy should fork a request. 

As further noted above, Sanchez is directed to a method and apparatus for networks 
which enable the appropriate server to be found for providing a specific user with a specific 
service, where a UDS responds to a query pertaining to a specific user by redirecting the query to 
the appropriate server or serving entity, in a network having multiple servers. 

[001 1] Embodiments of the present invention solve the problem discussed 
above by placing a user identification distributor accessible to an entity 
disposed to request user information. The distributor, or User Distribution 
Server (UDS) comprises a plurality of user identifiers per subscriber basis 
that are intended for identifying a user under different service 
environments. The UDS responds to a query pertaining to a specific user 
by redirecting the query to the appropriate server or serving entity, in a 
network having multiple servers. It is to be understood that "redirecting" 
in this context means answering the query with a server identifier, for the 
requester node issuing a new query towards the server. The UDS 
implements a secondary database with user and server identification 
information obtained from primary user databases, and is arranged for 
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determining a specific network server in charge of a given user under a 
particular service environment. These specific network servers are 
considered primary databases wherein subscribers, or more specifically, 
user data under particular service environment, are distributed. Thus, the 
UDS acts as a secondary database comprising means for recovering user 
identifiers and necessary service data from the specific network servers 
acting as primary databases as well as from other UDS in the network 
resolution domain. The UDS also comprise storage for user identifiers and 
necessary service data, if any, per specific network server. 

(Sanchez, pages 1-2, paragraph 1 1). 

Thus, because Sanchez' apparatus can determine the appropriate server/serving entity to 
which the query is to be re-directed, Sanchez, therefore, does not need to perform a sequential or 
parallel forking operations to identify the server, from the various servers or server entities, to 
which the query is to be re-directed. 

Accordingly, to modify Sanchez using Rosenberg so that the modified teachings would 
be one "in which the called party to be able to manipulate callers request and redirect the 
responses back based on the callers request or preferences" (as argued by the Examiner at page 4 
of the Office Action) so as to determine whether to fork the request in parallel or sequentially to 
multiple servers (corresponding to multiple contact addresses) would change Sanchez' principle 
of operation of redirecting the query to the appropriate server or serving entity. Such a 
modification would also render Sanchez unsatisfactory for its intended purpose. 

Accordingly, Appellants contend that the Examiner failed to establish a prima facie case 
of obviousness, and that for this reason too independent claim 1 is therefore allowable over the 
cited art, and the rejection under 35 U.S.C. § 103(a) of the claim should be withdrawn. 

(E) Conclusion. 

For the foregoing reasons, Appellants' independent claim 1, and claims 4-5 and 31-32, 
which depend from independent claim 1, are allowable over the cited art, and the Examiner's 
rejection of those claims should be withdrawn. Appellants' independent claims 1 1 and 20 recite 
features similar to those recited in claim 1, and, therefore, Appellants' independent claims 1 1 and 
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20, as well as claims 26-27 and 29-30 (which depend from independent claim 1 1) are allowable 
over the cited art for reasons similar to those provided with respect to independent claim 1 , and 
the Examiner's rejection of those claims should be withdrawn. 



(2) Claims 7 and 28 are patentable 
over the cited art. 

For the purposes of this appeal only, claims 7, and 28 stand or fall together. Claim 7 is 
representative of this group of claims. 

As noted, the Examiner rejected claim 7 as rendered obvious over Sanchez in view of 
Rosenberg. Claim 7, which depends from claim 1, recites "wherein the querying comprises 
applying a query to a sub-group of known contact addresses." 

As explained above in relation to claim 1 's feature of "querying", in some embodiments, 
the controller entity queries a database at a HSS for information regarding the manner in which 
the request for the communication link to the user is to be handled. Thus, in some embodiments 
of claim 7, querying the database at the HSS to determine the manner for handling a request for a 
communication link to a user may include applying such querying only to a sub-group of the 
plurality of contact addresses for the user. 

[0032] In the operation, a plurality of addresses for a user may be 
registered at a S-CSCF 12 at step 30 of FIG. 2. An incoming request may 
arrive at step 3 1 to the S-CSCF 12 to be terminated for the mobile user 1 . 
The user 1 has not indicated any q values via registration to the S-CSCF 
12. Neither does the incoming request have any preferences of the caller, 
for example by means of the Request-Disposition' header field. In such 
situation the S-CSCF 12 may query a user information database at step 32. 
The request may then be processed at step 33 in accordance with the user 
profile 22 stored in the HSS 20. 

[0033] For example, the user profile 22 may be configured to indicate the 
following alternatives: proxy to only a single contact (no forking), proxy 
the request to all known addresses at once (parallel forking), or proxy the 
request sequentially. In the last case the order may be randomly chosen 
(sequential search). In certain applications two options might be enough. 
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For example, the options may be no forking and sequential forking. More 
than three options may also be used. 

[0034] The processing may occur in accordance with the information from 
the user information storage only if no user preference has been indicated 
for the known contact addresses. For example, any preference indicated by 
the request may overrun the information from the user information 
storage. Alternatively, the user information may not even be queried if the 
request includes a preference, or if the preference is otherwise known. 

[0035] The query may only be applied to a sub-group of the known 
contact addresses. For example, the sub-group may include the WLAN or 
GPRS addresses in FIG. 1. 

(Specification, pages 9-10, paragraphs 32-35). 



In rejecting Appellants' claim 7, the Examiner contended that: 

Regarding claim 7, Sanchez and ROSENBERG, together taught the 
method as in claim 1 above. Sanchez further teaches wherein the querying 
comprises applying a query to a sub-group of the known contact addresses 
(Sanchez: [0045] e.g., a UDS arranged for acting as an SLF comprises at 
least one Protocol Handler module for handling the received and answered 
queries from and to the CSCF node; ROSENBERG: user plurality 
addresses [0002-0010]). 

(Emphasis in the original, Office Action, page 5). 

As explained above in relation to the Examiner's contentions that Sanchez discloses the 
features pertaining to "querying" as recited in claim 1 , Sanchez does not describe that a query 
sent by Sanchez' CSCF to the HSS is a query to get information regarding the manner on how to 
handle the request for a communication link to a user. Rather, all Sanchez discloses is that "the 
CSCF preferably launches a query directly to the HSS (Server-3) (S-40)" (Sanchez, pages 5-6, 
paragraph 62). Thus, because Sanchez does not disclose that a query sent to the HSS to 
determine the manner of handling a request for a communication link to a user, Sanchez, 
therefore, cannot and does not disclose that querying includes applying a query to a sub-group of 
known contact addresses of the user that the calling party is requesting a communication link to. 
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Accordingly, Sanchez fails to disclose or suggest at least the features of "wherein the 
querying comprises applying a query to a sub-group of known contact addresses," as recited in 
Appellants' claim 7. 

Furthermore, the passage in Sanchez referred to by the Examiner in the Examiner's 
rejection of claim 7 provide as follows: 

[0045] Therefore, a UDS arranged for acting as an SLF comprises at least 
one Protocol Handler module for handling the received and answered 
queries from and to the CSCF node. Moreover, provided that the protocol 
suitable for communication between SLF and HSS is other than the one 
between SLF and CSCF, the UDS arranged for acting as an SLF 
comprises another Protocol Handler Module (PHM) for handling updates 
or downloads with the HSS. As already mentioned, a Protocol 
Discriminator Module (PDM) is included in a UDS where more than one 
PHM is used. 

(Sanchez, page 5, paragraph 45). 

Contrary to the Examiner's contentions, nothing in the above passage describes applying 
a query (e.g., to get information on the manner of handling a request for a communication link to 
a user) to a sub-group of known contact addresses. 

Accordingly, for this reason too, Sanchez fails to disclose or suggest at least the features 
of "wherein the querying comprises applying a query to a sub-group of known contact 
addresses," as recited in Appellants' claim 7, and Rosenberg fails to cure the deficiencies of 
Sanchez as they relate to the teachings of this feature. 

Because none of the references discloses or suggests, alone or in combination, at least the 
features of "wherein the querying comprises applying a query to a sub-group of known contact 
addresses," claim 7 is allowable over the cited art, and the Examiner's rejection under 35 U.S.C. 
§ 103(a) of this claim should be withdrawn. 

Appellants' claim 28 recite features similar to those recited in claim 7, and, therefore, 
claim 28 is allowable over the cited art for at least reasons similar to those provided with respect 
to claim 7, and the Examiner's rejection of claim 28 under 35 U.S.C. § 103(a) should be 
withdrawn. 
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(3) Claims 8 and 9 are patentable 
over the cited art. 

For the purposes of this appeal only, claims 8 and 9 stand or fall together. Claim 8 is 
representative of this group of claims. 

As noted, the Examiner rejected claim 8 as rendered obvious over Sanchez in view of 
Rosenberg. Claim 8, which depends from claim 1, recites "further comprising indicating and 
assigning handling instructions for at least one contact address independently during registration 
of the at least one contact address." 

Thus, in some embodiments of claim 8, different contact addresses may be independently 
assigned handling instructions such that, in some implementations, one contact address of a user 
(being called) may have one set of handling instructions, and another contact address for that 
user may have other, different, handling instructions. 

[0032] In the operation, a plurality of addresses for a user may be 
registered at a S-CSCF 12 at step 30 of FIG. 2. An incoming request may 
arrive at step 3 1 to the S-CSCF 12 to be terminated for the mobile user 1 . 
The user 1 has not indicated any q values via registration to the S-CSCF 
12. Neither does the incoming request have any preferences of the caller, 
for example by means of the , Request-Disposition A header field. In such 
situation the S-CSCF 12 may query a user information database at step 32. 
The request may then be processed at step 33 in accordance with the user 
profile 22 stored in the HSS 20. 

[0033] For example, the user profile 22 may be configured to indicate the 
following alternatives: proxy to only a single contact (no forking), proxy 
the request to all known addresses at once (parallel forking), or proxy the 
request sequentially. In the last case the order may be randomly chosen 
(sequential search). In certain applications two options might be enough. 
For example, the options may be no forking and sequential forking. More 
than three options may also be used. 

[0034] The processing may occur in accordance with the information from 
the user information storage only if no user preference has been indicated 
for the known contact addresses. For example, any preference indicated by 
the request may overrun the information from the user information 
storage. Alternatively, the user information may not even be queried if the 
request includes a preference, or if the preference is otherwise known. 
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[0035] The query may only be applied to a sub-group of the known 
contact addresses. For example, the sub-group may include the WLAN or 
GPRS addresses in FIG. 1. 

[0036] Handling instructions may be indicated and assigned for each 
contact address independently during their registration at the controller 
entity 12. The handling instructions may be indicated and assigned for 
each contact address by the user equipment 1 or the user information 
storage. 

(Specification, pages 9-10, paragraphs 32-36). 



In rejecting Appellants' claim 8, the Examiner contended that: 

Regarding claim 8, Sanchez and ROSENBERG, together taught the 
method as in claim 1 above, as described above. Sanchez further teaches 
wherein indicating and assigning handling instructions for at least one 
contact address independently during registration of the at least one 
contact address (Sanchez: [001 1] e.g., plurality of user identifiers under 
different service environments; ROSENBERG: user plurality addresses 
[0002-0010]). 

(Emphasis in the original, Office Action, page 5). 



The passage in Sanchez referred to by the Examiner in the Examiner's rejection of claim 
8 provide as follows: 

[001 1] Embodiments of the present invention solve the problem discussed 
above by placing a user identification distributor accessible to an entity 
disposed to request user information. The distributor, or User Distribution 
Server (UDS) comprises a plurality of user identifiers per subscriber basis 
that are intended for identifying a user under different service 
environments. The UDS responds to a query pertaining to a specific user 
by redirecting the query to the appropriate server or serving entity, in a 
network having multiple servers. It is to be understood that "redirecting" 
in this context means answering the query with a server identifier, for the 
requester node issuing a new query towards the server. The UDS 
implements a secondary database with user and server identification 
information obtained from primary user databases, and is arranged for 
determining a specific network server in charge of a given user under a 
particular service environment. These specific network servers are 
considered primary databases wherein subscribers, or more specifically, 
user data under particular service environment, are distributed. Thus, the 



-47- 



Attorney's Docket No.: 39700-79300 1US/NC39973US 
Customer Number: 64046 

UDS acts as a secondary database comprising means for recovering user 
identifiers and necessary service data from the specific network servers 
acting as primary databases as well as from other UDS in the network 
resolution domain. The UDS also comprise storage for user identifiers and 
necessary service data, if any, per specific network server. 

(Sanchez, pages 1-2, paragraph 11). 

While Sanchez describes that a plurality of user identifiers for identifying a user under 
different service environments is downloaded to Sanchez' Distribution Server (UDS), nothing in 
the above paragraph, or elsewhere in Sanchez, describe that handling instructions for the various 
identifiers in the plurality of user identifiers are independently assigned or are associated with 
different handling instructions. 

Accordingly, contrary to the Examiner's contentions, Sanchez fails to disclose or suggest 
at least the features of "further comprising indicating and assigning handling instructions for at 
least one contact address independently during registration of the at least one contact address," as 
recited in Appellants' claim 8, and Rosenberg fails to cure the deficiencies of Sanchez as they 
relate to the teachings of this feature. 

Because none of the references discloses or suggests, alone or in combination, at least the 
features of "further comprising indicating and assigning handling instructions for at least one 
contact address independently during registration of the at least one contact address," 
Appellants' claim 8 is allowable over the cited art, and the Examiner's rejection under 35 U.S.C. 
§ 103(a) of this claim should be withdrawn. 

Appellants' claim 9 depends from claim 8 and is therefore allowable over the cited art for 
at least reasons similar to those provided with respect to claim 8, and the Examiner's rejection of 
claim 9 under 35 U.S.C. § 103(a) should be withdrawn. 
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CONCLUDING REMARKS 

For the foregoing reasons, as well as the reasons provided in Appellants' Pre- Appeal 
Brief Request for Review, dated February 9, 201 1, Appellants submit that claims 1, 4-5, 7-9, 11, 
20, 23, and 26-32 are allowable. Therefore, the Examiner erred in rejecting Appellants' claims 
and should be reversed. 



Respectfully submitted, 

Dated: June 17,2011 

/Ido Rabinovitch/ 

Ido Rabinovitch 
Reg. No. L0080 
Attorney for Appellants 

Customer No. 64046 

Mintz, Levin, Cohn, Ferris, Glovsky and Popeo, P.C. 
701 Pennsylvania Ave., NW, Suite 900 
Washington, DC 20004 
Telephone: 202-434-7434 
Facsimile: 202-434-7400 
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(viii) Claims Appendix 

1. A method, comprising: 

registering, in a controller entity comprising a call state control function, a plurality of 
contact addresses for a user; 

receiving, at the controller entity, a request for a communication link to the user; 

querying, by the controller entity, a database at a home subscriber server for information 
regarding a manner regarding how to handle the request; and 

processing, at the controller entity, the request based on the queried information from the 
database, wherein, when provided during registration, the controller entity uses user preference 
information to determine whether to fork the request in parallel or sequentially. 

2. -3. (Cancelled) 

4. The method as claimed claim 1, wherein the registering comprises registering the 
plurality of contact addresses for the user in the controller entity which is provided in association 
with a multimedia network. 

5. The method as claimed in claim 1, wherein the registering comprises the user 
registering the plurality of contact addresses in at least two different communication networks. 

6. (Cancelled) 

7. The method as claimed in claim 1, wherein the querying comprises applying a query 
to a sub-group of known contact addresses. 
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8. The method as claimed claim 1, further comprising indicating and assigning handling 
instructions for at least one contact address independently during registration of the at least one 
contact address. 

9. The method as claimed in claim 8, wherein the indicating and assigning comprises 
indicating and handling the handling instructions for the at least one contact address by either the 
user or the database. 

10. (Canceled) 

1 1 . An apparatus, comprising: 
at least one processor; and 

at least one memory, wherein the at least one processor and the at least one memory 
provide operations comprising: 

registering, in a controller entity comprising a call state control function, a plurality of 
contact addresses for a user; 

receiving, at the controller entity, a request for a communication link to the user; 

querying, by the controller entity, a database at a home subscriber server for information 
regarding a manner regarding how to handle the request; and 

processing, at the controller entity, the request based on the queried information from the 
database, wherein, when provided during registration, the controller entity uses user preference 
information to determine whether to fork the request in parallel or sequentially. 

12. -19. (Cancelled) 

20. An apparatus comprising: 

registration means for registering, in a controller entity comprising a call state control 
function, a plurality of contact addresses for a user; 
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interface means, at a controller entity, for interfacing to a database for storing information 
regarding how to handle a request for the user; 

querying means for querying, by the controller entity, the database at a home subscriber 
server for information regarding a manner regarding how to handle the request; and 

processing means for processing, at the controller entity, the request based on the queried 
information from the database, wherein, when provided during registration, the controller entity 
uses user preference information to determine whether to fork the request in parallel or 
sequentially. 

21.-25. (Canceled) 

26. The apparatus as claimed claim 1 1 , wherein the apparatus is provided in association 
with a multimedia network. 

27. The apparatus as claimed in claim 11, wherein the registering is configured to 
register the plurality of contact addresses in at least two different communication networks. 

28. The apparatus as claimed in claim 11, wherein the querying applies a query to a sub- 
group of known contact addresses. 

29. The apparatus as claimed claim 11, further comprising receiving handling 
instructions for at least one contact address during registration of the at least one contact address. 

30. The apparatus as claimed in claim 29, wherein the handling instructions are received 
from at least one of the user or the database. 

3 1 . The method of claim 1 , wherein the request comprises a session initiation protocol 
request. 
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32. The method of claim 1, wherein the call state control function is a serving call state 
control function. 
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